System for context transfer for wireless internet devices

ABSTRACT

A system and method for feature context transfer store all currently “active” feature contexts locally at an Access Router (AR), and store all “inactive” feature contexts centrally in a main database. The main database can be accessed by all the ARs within the same administrative domain. When a new microflow becomes active, its active feature contexts are brought from the main database and loaded into the local directory, thus replacing any inactive feature contexts that are not needed at the time.

CROSS REFERENCE TO RELATED APPLICATION(S)

This application is a continuation of U.S. patent application Ser. No.10/317,769 filed on Dec. 12, 2002, now U.S. Pat. No. 7,974,294 thatissued on Jul. 5, 2011, which claims priority from U.S. ProvisionalPatent Application No. 60/340,417, filed Dec. 14, 2001, which isincorporated by reference as if fully set forth.

FIELD OF INVENTION

The present invention relates to the field of communications. Morespecifically, the present invention relates to supporting microflows bythe mobile Internet, and to a context transfer approach to supportingmicroflows.

BACKGROUND

The Internet is increasingly being used to support mobile applications.There a growing need to support many different types of microflows,including both real-time and non real-time services.

In a mobile environment, microflows emanating from a Mobile Node (MN)are characterized by a set of parameters. The parameters define acontext and the resulting feature contexts may be stored within anaccess router (AR).

Some features are specifically defined for a particular microflow, whileothers are defined for all the microflows belonging to the MN. Thesefeatures may be for defining the QoS state, (such as RSVP, DiffServ,COPS), maintaining robust header compression, (such as van Jacobson andGRE), and security, (such as PKI and AAA). In order to assist inpreserving the network bandwidth, it is desirable to store theseparameters at some node entity within the access network, instead of atthe MN itself. By doing that, the overhead of processing andtransmission delay from the MN to the AR is greatly reduced. This savesthe transmission bandwidth through the radio link and makes the designof the MN much simpler.

The context transfer protocol is tightly integrated into the handoverprotocols currently developed by the IETF, such as: Fast Handovers forMobile IPv6, Low Latency Handoffs in Mobile IPv4, and Bi-directionalEdge Tunnel Handover for IPv6. It must support seamless (i.e.uninterrupted), loss-less, resumption of services after the handover iscompleted. Therefore, an essential requirement of context transfer isthat there must be good synchronization between the handover protocoland the context transfer method, and the context transfer must bereliable.

The protocol must maintain the integrity of data during the contexttransfer. There must be security association between the two ARs so thatthey can mutually authenticate themselves prior to the transfer ofcontext. The context transfer protocol must also minimize the amount ofprocessing at the sending and receiving ARs, and it must complete thecontext transfer with a minimum number of signaling messages.

It would also be desirable for the context transfer protocol to bescalable. Scalability means that the context transfer protocol shouldscale with the number of participating MNs, and that it should scalewith the number of feature contexts and feature contexts beingtransferred.

SUMMARY

The present invention is a system and method which stores all currently“active” feature contexts locally at the ARs, and stores all “inactive”feature contexts centrally in a main database. The main database can beaccessed by all the ARs within the same administrative domain. When anew microflow becomes active, its active feature contexts are broughtfrom the main database and loaded into the local directory, thusreplacing any inactive feature contexts that are not needed at the time.

BRIEF DESCRIPTION OF THE DRAWING(S)

FIG. 1 is a block diagram of the architecture for performing contexttransfer between a pair of ARs.

FIG. 2 depicts a context transfer L3 trigger message.

FIG. 3 depicts a context transfer L3 acknowledgement message.

FIG. 4 illustrates an ICMP Message Format for CTR, CTA and CTD.

FIG. 5 depicts the format of feature context object(s) message.

FIG. 6 illustrates format of a context transfer object.

FIG. 7 depicts a context transfer ESP message format.

FIG. 8 is a flow diagram of a method for feature context transfer.

Tables 1 and 2 provide an overview of the acronyms used in the figuresrelating to the entities and the signals, respectively.

TABLE 1 ENTITIES ACRONYM MEANING LCD Local Context Directory CTA ContextTransfer Agent MTA Memory Transfer Agent MN Mobile Node AR Access RouterMCD Main Context Database MGL Memory Gateway (local) MGE Memory Gateway(external)

TABLE 2 ENTITIES ACRONYM MEANING CTR Context Transfer Request CTAContext Transfer Accept CTD Context Transfer Denied CTINIT ContextTransfer Initiate CTACK Context Transfer Acknowledge FCR Feature ContextRequest FCA Feature Context Accept FCD Feature Context Denied

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

The preferred embodiment will be described with reference to the drawingfigures wherein like numerals represent like elements throughout.

As an overview of the present invention, feature contexts are maintainedwithin each AR for every MN that is connected to that AR. The featurecontexts define the microflows of an MN. These feature contexts may be“active” or “inactive” depending on whether or not the MN needs to makeuse of it at that time. If at anytime during a session an MN wishes toinitiate a handover from its current AR (hereinafter “oldAR”) to adifferent AR (hereinafter “newAR”), it sends a Context Transfer Initiate(CTINIT) message to the oldAR. This message may be in the form of alayer 2 (L2) trigger or it may be a special layer 3 (L3) packet.Included in the trigger message is the identity of the newAR to whichthe feature contexts are being transferred. After the oldAR hasdetermined the identity of the newAR, it sends a Context TransferRequest (CTR) message to the newAR. The newAR may choose to accept orreject this request. If the CTR is accepted, the newAR sends back aContext Transfer Accepted (CTA) message; otherwise, it sends back aContext Transfer Denied (CTD) message to the oldAR. If the featurecontext transfer request is accepted, the active feature contexts forthe MN are transferred from the oldAR to the newAR. If, on the otherhand, the feature context transfer request is denied, then the MNattempts to find another newAR as a new target for the context transfer.

Referring to the block diagram of FIG. 1, the present invention will bedescribed in detail. The system 4 for performing a feature contexttransfer between a pair of ARs (from an oldAR 6 to a newAR 8), includesa Main Contact Database (MCD) 24, a Memory Gateway (external) (MGE) 26,a Memory Gateway (local) (MGL) 22, a plurality of ARs 6, 8 and aplurality of MNs 28, (only one of which is shown in FIG. 1 forsimplicity).

It should be noted that although the system 4 shown in FIG. 1 pertainsto a single administrative domain, (i.e. of all the entities under theMCD 24), it would be understood by those of skill in the art, (as alsoshown in FIG. 1) that there are connections to other ARs within thedomain under the MGL 22, and also connections outside the domain via theMGE 26.

The MCD 24 is a database that contains the feature contexts for all MNs28 being served in the domain. This includes the feature contexts forall active and inactive microflows. The MGE 26 is a control entity thatprovides an interface between different Memory Transfer Agents (MTA)belonging to different domains. The MGL 22 is a control entity thatprovides an interface between different local MTAs belonging to the samedomain. The ARs 6, 8 are control units that provide an interface to theInternet Protocol (IP) network. The ARs 6, 8 are responsible forassigning an IP address, (or any other type of address), to the MNs 28.

Each AR 6, 8 includes a Local Context Directory (LCD) 10, a MemoryTransfer Agent (MTA) 12 and a Context Transfer Agent (CTA) 14. The LCD10 maintains the list of feature contexts for active microflows for allMNs 28 associated with that particular AR 6, 8. The CTA 14 is a controlentity that is responsible for establishing the contacts with the newpoint of attachment (i.e. the newAR 8) in order to transfer the activefeature context to the newAR 8. The MTA 12 is a control entity that isresponsible for transferring the context of the LCD 10 to the LCD 10newAR 8.

The system 4 of the present invention utilizes selective transfer offeature context data. The feature contexts are separated into twocategories: 1) feature contexts belonging to “active” microflows; and 2)feature contexts belonging to “inactive” microflows. As those of skillin the art would realize, an active microflow is one which is currentlyin progress sending traffic; whereas an inactive microflow is one whichis suspended or stopped altogether. All the active feature contexts haveto be available inside the LCD 10 of the AR (oldAR 6 and new AR 8),while the inactive feature contexts are stored in the MCD 24. Whenever anew microflow becomes active, its feature contexts are brought from theMCD 24 via the MGL 22 and loaded into the LCD 10, thereby overwritingany inactive feature contexts that may be present there. In accordancewith the present invention, it is not necessary to store all of thefeature contexts locally at the ARs 6, 8, it is only necessary to storelocally the feature contexts of the active microflows. This helps tosignificantly reduce the size of the LCD 10 since the feature contextsfor the inactive microflows can be accessed from the MCD 24 when needed.This also reduces the time required for the feature context transfer andalso reduces the bandwidth and processing overhead.

The process of handover from the oldAR 6 to the newAR 8 initiates thefeature context transfer process. To start the transfer of featurecontexts, the MN 28 sends a “trigger” signal to the CTA 14 in the oldAR6 through the wireless interface. This trigger signal may be in the formof a L2 trigger message, or it may be a separate IP packet.

This message is called Context Transfer Initiate (CTINIT). The CTINITcomprises an ICMP Echo Request message. The format of the CTINIT messageis shown in FIG. 2. A description of the terminology used in FIG. 2follows in Table 3:

TABLE 3 FIELD DESCRIPTION TYPE Echo Request- value 8 CODE CTINIT - codevalue 1 CHECKSUM The 16-bit one's complement of the one's complement sumof the ICMP message, starting with the ICMP Type. For computing thechecksum, the checksum field is set to 0. IDENTIFIER unused, providedfor future flexibility. SEQUENCE unused, provided for futureflexibility. NUMBER NUM ADDRS The address of the prospective newAR. ADDRENTRY The number of 32-bit words of information per SIZE each routeraddress, (preferably 2). LIFETIME The maximum number of seconds that theAR addresses may be considered valid. MN's IDENTITY NAI or L2 address.oldAR's IP Current AR's IP address. ADDRESS NewAR's IP [i] Prospectivetarget AR's IP address(es), (i = ADDRESS 1 . . . NUM ADDRS): PreferenceThe preferability of each newAR[i] as i = 1 . . . NUM Level[i] ADDRS thecandidate target AR, relative to other AR addresses in the same domain.A signed, two's-complement value; higher values mean more preferable.

The CTINIT message provides a list of “target” newAR 8 along with theirassociated information. The associated information can change as desiredby the system operator, but preferably comprises the fields shown inFIG. 2. For example, the preference level is a value assigned to each ARin the domain. The preference level may be based on any criteria set bythe operator, or may be made the same for all ARs. Preferably, thepreference level for each AR in the domain is different, and the presentinvention, will be described as such. The oldAR 6 selects the newAR 8with the highest preference value. However, if that newAR 8 denies theCTR request, the newAR 8 the next highest preference value is targeted.

After the MN 28 has transmitted the CTINIT message, it waits to receiveback a Content Transfer Acknowledgement (CTACK) message. The CTACKmessage comprises an ICMP Echo Reply message. If no CTACK message isreceived within a timeout period, the MN 28 retransmits the CTINITmessage. This is done repeatedly until either a CTACK is received, or amaximum count of retries has been reached, whereby the feature contexttransfer to that newAR 8 is abandoned and another newAR 8 is targeted.The format of a CTACK message is shown in FIG. 3. A description of theterminology used in FIG. 3 follows in Table 4:

TABLE 4 FIELD DESCRIPTION TYPE Echo Reply - code value 0 CODE CTACK -code value 1 CHECKSUM The 16-bit one's complement of the one'scomplement sum of the ICMP message, starting with the ICMP. Forcomputing the checksum, the checksum field is set to 0. IDENTIFIERunused, provided for future flexibility. SEQUENCE unused, provided forfuture flexibility. NUMBER MNs IDENTITY (NAI or L2 address)

No CODE value is currently used with the CTACK Echo Reply message. Forthe CTACK message, the MN's identity is echoed back to the MN 28, sothat it can match it with the MN's identity previously sent with theCTINIT message.

After the CTINIT message is received, the CTA 14 in the oldAR 6 sends aContext Transfer Request (CTR) message to the CTA 14 of the newAR 8.Upon receiving the CTR message, the CTA 14 in the newAR 8 authenticatesthe oldAR 6.

Authentication ensures that the oldAR 6 is to be trusted and theinformation conveyed is correct. The authentication process is notcentral to the present invention and there are many such processes whichare well known in the art that may be used. However one process forauthentication is done by establishing a Security Association (SA)between the oldAR 6 and the newAR 8. Each SA is given a number, known asa Security Parameters Index (SPI), through which it is identified. Inorder for the oldAR 6 and the newAR 8 to mutually authenticatethemselves, the oldAR 6 must know the SPI value of the newAR 8.Likewise, the newAR 8 must know the SPI of the oldAR 6. The oldAR 6sends its SPI value with the payload to the newAR 8, using a normal IProuting header. The newAR 8 verifies the SA by noting the SPI, and sendsback a CTA if the context transfer request is accepted. When sending theCTA message, the newAR 8 also forwards its SPI value to the oldAR 6.Thus, in a similar manner, the oldAR 6 verifies the SA by noting the SPIvalue of the newAR6.

The newAR 8 sends back a Context Transfer Accepted message (CTA) if theCTR is accepted, or a Context Transfer Denied message (CTD) if the CTRis denied. If the CTR is accepted, then the feature context transfer canproceed normally, otherwise the context transfer is not permitted toproceed to that particular newAR 8.

The message formats for the CTR, CTA are also ICMP messages. CTR is anICMP Echo Request, while CTA and CTD comprise ICMP Echo Reply. Theformat of the ICMP message for the CTR, CTA and CTD messages is shown inFIG. 4. A description of the terminology shown in FIG. 4 follows inTable 5:

TABLE 5 FIELD DESCRIPTION TYPE 8 - Echo Request, 0 - Echo Reply CODE 2 -CTR, 2- CTA, 3 - CTD CHECKSUM The 16-bit one's complement of the one'scomplement sum of the ICMP message, starting with the ICMP TYPE. Forcomputing the checksum, the checksum field is set to 0. IDENTIFIER usedfor matching CTRs from sending. SEQUENCE AR with CTAs or CTDs fromreceiving AR. NUMBER MN's ADDRESS Provided in CTR message only. Thisfield is absent in CTA and CTD messages.

When the CTR is accepted, and the CTA message is sent back to the oldAR6, the transfer of all active feature contexts for the particular MN 28from the LCD 10 in the oldAR 6 to the LCD 10 in the newAR 8 isperformed. This transfer may be accomplished using any of the datatransfer and handshaking protocols that one known in the art to transferdata between two entities. Several messages are exchanged between thetwo ARs 6, 8 to insure connectivity and authenticity as well as theinformation being transferred.

Preferably the active feature contexts of the MN 28 that are resident inthe LCD 10 of the oldAR 6 are transferred from the oldAR 6 to the LCD 10of newAR 8 in an ESP encapsulated IP datagram. The innermost IP datagramcontains a common IP header, and following that is a set of featurecontext objects. The basic structure of this datagram is shown in FIG.5.

The format of a CT object is shown in FIG. 6. The basic structurecomprises a CT header and a listing of the feature context parameters. Adescription of the terminology used in FIG. 6 follows in Table 6:

TABLE 6 FIELD DESCRIPTION TYPE The type of feature context beingtransferred, (i.e. whether it's RSVP, iffServ, RoHc, AAA keys, etc.) Thetype value is unique to the specific type of feature context beingtransferred. CODE Within each TYPE, a number of different objects may bedefined. For example, RSVP defines SENDER_TSPEC, ADSPEC and FLOWSPECobjects; DiffServ defines DSCP's to emulate PHB's in a DifferentiatedServices network; AAA registration keys. Thus, parameters are groupedinto different sets, as indicated by the CODE values. Each particularset of parameters within a given class, is transmitted from the sendingAR to the receiving AR as a separate CT object. RES unused, provided forfuture flexibility. L Last object transmitted. If a CT object with theL-bit set is not received within a timeout period, a suitable NAKmessage is sent to the sending AR. Also, if a CT object follows the CTobject with the L-bit set, a similar NAK message is sent to the sendingAR, indicating an error. SEQUENCE Used for maintaining the order oftransmissions NUMBER of CT objects, and also for reliability purposes.If a gap in sequence number occurs, a NAK packet is sent to the sendingAR, indicating the sequence number of the object that was not received.NUM PARAMS Number of feature context parameters transferred in thisobject. LIFETIME The maximum number of seconds that the context transferobject may be considered valid. CHECKSUM The 16-bit one's complement ofthe one's complement sum of the CT object, starting with the ICMP Type.For computing the checksum, the Checksum field is set to 0. MN'sIDENTITY MN's NAI or L2 identifier. PARAMETER(S) List of feature contextparameters.

It should be noted that all context transfer messages between the oldAR6 and newAR 8 are encapsulated with IPsec ESP, to handle security ofdata. During the establishment of sessions between the ARs, the CTR, CTAor CTD messages are represented by ICMP packets and placed in thedatagram portion of the IP packet. Any feature context to be transferredbetween the ARs 6,8 are likewise encapsulated in standardized objectsand placed in the datagram portion of the IP packet. A TCP header, ESPheader and ESP trailer segments are added as shown in FIG. 7. Theresulting packet is then encrypted, to preserve the privacy andintegrity of its contents. An ESP authentication field is added to endof the encrypted packet, and an IPv4 routing header is added to thebeginning of the packet. The routing header must be the same as theinnermost IP header.

The reliability of context transfer signaling messages, (CTINIT, CTACK,CTR, CTA and CTD), is provided by the 16-bit checksum in the ICMPheader. The checksum is recomputed by the newAR 8, and the resultingvalue is compare with the value in the checksum field of the message.Any mismatch is flagged as an error, and a NAK is returned indicatingthe SEQUENCE NUMBER of the erroneous message in the IDENTIFIER field.The original message is then retransmitted by the original sender.

Another source of error may be due to mismatch in the actual andcomputed checksum in the CT object header. If this occurs, a NAK is sentto the oldAR 6, indicating the SEQUENCE NUMBER of the erroneous CTobject in the IDENTIFIER field. The NAK may be piggybacked onto anothermessage, or sent as a separate message altogether. The resulting CTobject is retransmitted as part of the same context transfer message, oras a new context transfer message.

When a new feature context is desired, a signal called Feature ContextRequest (FCR) is issued by the CTA 14. This message may be in the formof an ICMP datagram, including appropriate TYPE, CODE values and theidentity of the MN 28. On receiving the FCR message, the MTA 14 maychoose to accept (FCA) or deny (FCD) the request. These two messages mayalso be in the form of an ICMP datagram. The FCR may be accepted ifthere is sufficient space in the LCD 10 to store all the parametersassociated with the feature context. If the FCR is accepted, the featurecontext parameters are brought from the MCD 24 into the LCD 10 in thenewAR 8.

Referring to FIG. 8, a procedure 100 in accordance with the presentinvention is shown. The procedure 100 transfers active feature contextfrom an oldAR 6 to a newAR 8. The procedure 100 starts with all featurecontexts (both active and inactive) being stored at the MCD 24, but onlyactive feature context being stored at the oldAR 6 (step 102). Oncehandover is initiated, a retry parameter is initialized (step 104). Theretry parameter keeps track of the number of retries the MN 28 has madein order to send the CTACK message. The MN 28 sends the CTINIT messageto the oldAR 6 (step 106) and awaits a CTACK message (step 108). The MN28 determines whether it has received a CTACK message (step 110). If theMN 28 has not received a CTACK message then the MN determines whether atimeout period has expired (step 112). If the timeout period has notexpired, the MN 28 returns to step 108 to await the CTACK message. Ifthe timeout period has expired, the retry parameter is increased by 1(step 114) and the MN 28 determines whether the maximum number ofretries has been reached (step 116). If the maximum number of retrieshas not been reached the MN 28 returns to step 106 and resends theCTINIT message. If the maximum number of retries has been reached, thefeature context transfer to that newAR 8 is abandoned and another newAR8 may be targeted (step 118).

Once the MN 28 determines that it has received a CTACK message asdetermined at step 110, the CTA 14 in the oldAR 6 sends a CTR message tothe CTA 14 in the newAR 8 (step 120). The CTA 14 in the new AR 8authenticates the oldAR 6 (step 122) and the CTA 14 in the newAR 8 sendsback to the CTA 14 in the oldAR 8 a CTA message if accepted, and sendsback a CTD message if denied (step 124).

If a CTA message has been received by the MN 28 (step 126), only theactive feature context are transferred from the oldAR 6 to the newAR 8.If the CTA message has not been received by the MN 28 as determined atstep 126, step 118 is entered whereby a different newAR 8 is targetedfor context transfer.

Although the present invention is directed to a feature context transferprotocol for context transfers between an oldAR 6 and a newAR 8 withinthe same domain, it should be understood by those of skill in the artthat in the event an MN 28 handoffs to a newAR in a differentadministrative domain, the process of transferring feature contextsbetween the LCDs 10 is also the same as hereinbefore described. However,in addition to the transfer of the active feature contexts between theLCDs, the inactive feature contexts are moved as well, from the currentMCD 24 to a new MCD in the new domain. The MCD 24 transfer isaccomplished via the MGE 26.

1. A communication domain having a central node coupled with at least afirst access router (AR) and a second AR, each of said ARs being inwireless communication with at least one mobile node (MN) via at leastone active microflow, the communication domain including a system fortransferring an MN from said first AR to said second AR in the event ofa handover, the system comprising: a central database at said centralnode for storing feature contexts for all microflows in thecommunication domain, said feature contexts comprising active featurecontexts for active microflows and inactive feature contexts forinactive microflows; a local database at each AR, each local databasefor storing active feature contexts for each active microflow to a NM;and a memory transfer agent at each AR, for handling the transfer ofonly said active feature contexts are from said first AR to said secondAR in the event of a handover.
 2. The system of claim 1, whereininactive feature contexts may also be stored in each said localdatabase.
 3. The system of claim 2 wherein said forwarded active featurecontexts overwrite inactive feature contexts.
 4. The system of claim 1,further comprising a context transfer agent (CTA) at each AR, fordetermining whether said forwarding of said active feature contexts mayproceed.
 5. A method for transferring context data from a first accessrouter (AR) to a second AR upon handover within a domain containing aplurality of ARs, said first and second ARs being coupled to a centralnode, and said first AR being wirelessly coupled to a mobile node (MN),said wireless coupling including an active microflow, the methodcomprising: storing all feature contexts related to all microflowswithin the domain at the central node; storing active feature contextsrelated to said active microflow at said first AR; and initiatinghandover to said second AR, including forwarding said active featurecontexts to said second AR.
 6. A method for transferring context datafrom a first access router (AR) to a second AR upon handover within adomain containing a plurality of ARs, said first and second ARs beingcoupled to a central node, and each AR being wirelessly coupled to amobile node (MN) via an active microflow, the method comprising: storingall feature contexts related to all microflows within the domain at thecentral node; storing active feature contexts related to an activemicroflow at said first AR; and forwarding only said active featurecontext from said first AR to said second AR.